Re: Recent troubles
der Mouse (mouse@Collatz.McRCIM.McGill.EDU)
Wed, 25 Jan 1995 09:32:13 -0500
>>>> If I had source, I'd probably corrupt tcp_iss on not only received
>>>> packets but also [...].
>>> You should read RFC 793 (if you haven't).
> I did, but not to the list.
That's why I identified you only as "someone" when I posted to the
whole list.
>> Several factors combine to make me ignore this risk. [that sequence
>> numbers will be re-used and old segments will confuse new
>> connections]
>> First is that, assuming the method does generate reasonably random
>> ISNs, it's unlikely. For a 4K maximum window size, it would require
>> a one-in-a-million coincidence (4G/4K) [and for a half-meg window,
>> it's one in 8192].
> how quickly can you send 1MB of data from host to host ?
> 10 seconds (best) ?
I'm not sure what you point is. You mean that small windows slow down
data transfer? True, and also largely irrelevant; I have no control
over the window size. You mean that I should be using 1Mb rather than
one window size? I disagree, because what matters is whether the
segment is in-window at the instant it arrives.
>> Third is that the new connection must use exactly the same port
>> numbers as the old. Unless the other end of the connection crashes
>> too, this is extremely unlikely because it will have a TIME_WAIT
>> socket sitting around preventing this.
> What about SO_REUSEADDR or do you disable this in all programs you
> compile ? (A lot enable it to stop TIME_WAIT connections building up
> in the kernel).
This is an abuse of SO_REUSEADDR. IME turning it on does not prevent
the creation of TIME_WAIT sockets (not connections); all it does is
cause the bind() call to ignore them when checking whether the address
is permitted. And yes, if I notice a gratuitous SO_REUSEADDR in a
program, I'll yank it out.
>> Fourth is the quiet time on TCP reboot, specifically for old
>> segments to run out of TTL. [...]
> eh ? TTL rarely works as you say...nearly always a hop count thing.
Perhaps you need to read RFC793. TTL is both a timeout and a hop
count; it is a timeout in seconds, but it also must be decremented by
at least one for each hop.
>> Unless of course you can suggest some better solution, [...]
> Oh, I thought it was obvious, just ensure that the seq# changes more
> often than it does and with some (large) uncertainty.
I thought that's what I was doing. :-)
> Although you have a nice CRC algorithm there, it (a) doesn't appear
> to handle the case where tcp_iss should wrap (TCP_COMPAT_42)
This I wasn't aware of. I will have to investigate.
> (b) can be calculated.
Yes. Because of this, I should also throw in something that doesn't
get revealed to the attacker, like the kernel VM addresses of the mbufs
holding the packet, like the result of uniqtime(), like the host ID
maybe even....
> Surely there is a timing routing in the kernel somewhere which you
> could plug a bit of extra assembly in...
Probably. But I've never seen a Sun with clock interrupts happening
oftener than 100Hz, which is way less than the 250KHz called for by
RFC793.
der Mouse
mouse@collatz.mcrcim.mcgill.edu